IAM Identity Center ユーザー向けにS3静的サイトを提供する【Verified Access】

IAM Identity Center ユーザー向けにS3静的サイトを提供する【Verified Access】

Clock Icon2024.09.05

本ブログでは IAM Identity Center ユーザー向けに「S3でホストしている静的サイト」を共有 してみます。

モチベーションは「AWS利用者に向けて情報を共有したい」です。 例えばAWS利用のルールやガイドラインなどです。 他のドキュメントプラットフォーム(Confluence, Backlog wikiなど) でも問題ありませんが、 できればAWSに関わる人に直接紐づけて共有したいなと思いました。

調べていたところ、以下ブログを拝見しました。

https://dev.classmethod.jp/articles/s3-content-delivery-from-alb/

https://dev.classmethod.jp/articles/verified-access-generally-available/

「これらを組み合わせればできるのでは?」と思い、実際にやってみました。

構成概要

以下ざっくりとした構成図です。

sc_2024-09-05_17-31-14_32016

「ALB → S3部分」と「Verified Access → ALB 部分」を、 もう少し詳しく説明します。

ALB → S3 部分

sc_2024-09-05_17-33-11_611

『静的サイト(S3)にプライベートアクセスできる環境』を作ります。 インターナルALBを作成します。 インターナルALBのターゲットとしてS3エンドポイント( インターフェイス型 )を指定します。

なお、この部分の構築手順は以下ブログとほぼ同じです。

https://dev.classmethod.jp/articles/s3-content-delivery-from-alb/

Verified Access → ALB 部分

sc_2024-09-05_17-42-47_6574

次に『認証されたユーザーのみ、この環境へアクセスできる仕組み』を作ります。

主要サービスは AWS Verified Access です。 Verified Access はアプリケーションへ安全にリモートアクセスしたいときに役立つサービスです。 ここでいうアプリケーションとは、 プライベートにあるロードバランサーやネットワークインターフェイスです。

サイトへのアクセス許可は、本ブログでは 「IAM Identity Center で管理しているユーザー全て」に与えます。 これは絞ることも可能です。

ユーザーはVerified Accessのエンドポイントへアクセスします。 IAM Identity Center の認証を経て、ALB(=S3静的サイト)へアクセスします。

構築する(ALB → S3部分)

まずは ALB → S3 部分を構築します。 先ほども言ったとおり すでにある quiver さんのブログ とほぼ同じです。

VPC, サブネット

VPCを作成します。 このVPCに今後 ALB を配置します。

またプライベートサブネットも作成しておきます。 最低 2AZ分、つまり2つのサブネットを用意します。 ※ ALB作成時には少なくとも 2AZ のサブネットを選択する必要があるため。

sc_2024-08-30_10-33-07_3330

セキュリティグループ

以下3つのセキュリティグループ(以降SG)を事前に作成しておきます。

用途 インバウンドルール アウトバウンドルール
Verified Access用 なし 全て許可
ALB用 Verified Access用SGからの HTTPS(443)を許可 全て許可
VPCエンドポイント用 ALB用SGからの HTTP(80),HTTPS(443)を許可 全て許可

sc_2024-08-30_10-42-26_27338

S3インターフェイス型VPCエンドポイント

ALBのターゲットとなるS3インターフェイス型VPCエンドポイントを作成します。

今回は1つのAZのみ指定します。IPアドレスを直打ちで設定します。

sc_2024-09-04_13-20-55_11639

作成時に先ほど作成したVPCエンドポイント用SGを設定します。

sc_2024-09-04_13-19-54_713

VPCエンドポイントのID(vpce-xxx)をメモしておきます。後ほどのバケットポリシーで必要です。

sc_2024-09-04_13-21-55_5086

S3バケット

アクセスさせるドメインと同じ名前のS3バケットを作成します。 後ほどのアクセステスト用に index.html を入れておきます。

sc_2024-09-04_13-11-55_1964

バケットポリシーにて、先程のVPCエンドポイント(vpce-xxx)からの GetObject を許可しておきます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Access-to-specific-VPCE-only",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": [
        "arn:aws:s3:::${S3バケット名}",
        "arn:aws:s3:::${S3バケット名}/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "${VPCエンドポイントID}"
        }
      }
    }
  ]
}

ACM証明書

アクセスさせるドメインのSSL/TLS証明書を発行しておきます。

ALBターゲットグループ

以下設定値のターゲットグループを作成します。

  • ターゲットタイプ: IPアドレス
  • ターゲットグループのプロトコル: HTTPS
  • ヘルスチェックのプロトコル: HTTP
  • ヘルスチェックのパス: /
  • ヘルスチェックの成功コード: 307
  • ターゲットのIPアドレス: (先程のS3エンドポイントのIPアドレス)

ALB

内部向けのALBを作成します。

  • セキュリティグループ: 先ほど作成したALB用SG
  • リスナーのプロトコル: HTTPS
  • リスナーのデフォルトアクション: 先ほど作成したターゲットグループに転送
  • リスナーの証明書: 先ほど作成したACM証明書

構築する(Verified Access → ALB部分)

次に Verified Access 部分の構築です。

以下順番で作成していきます。

  • Verified Access 信頼プロバイダー
  • Verified Access インスタンス
  • Verified Access グループ、グループポリシー
  • Verified Access エンドポイント
  • Route 53 CNAMEレコード

なお、Verified Access の各要素については以下ブログが参考になります。

https://dev.classmethod.jp/articles/aws-verified-access-components/

信頼プロバイダー

Verified Access 信頼プロバイダーを作成します。 信頼プロバイダータイプは IAM Identity Center を選択しましょう。

sc_2024-09-05_15-01-46_18493

インスタンス

Verified Access インスタンスを作成します。 その際に、先程作成した信頼プロバイダーを選択します。

sc_2024-09-05_15-02-43_23310

グループ, グループポリシー

Verified Access グループを作成します。 先程の作成したインスタンスを指定します。

sc_2024-09-05_15-05-18_20574

ポリシー部分には以下を記載します。 これは信頼プロバイダーの認証に成功したら無条件に接続できる内容です。

permit(principal,action,resource)
when {
    true
};

エンドポイント

Verified Access エンドポイントを作成します。 先ほど作成したグループを指定します。

sc_2024-09-05_15-27-18_17051

エンドポイントの詳細は以下のように指定します。

  • プロトコル: HTTPS
  • アタッチメントタイプ〜サブネット: ALBの情報
  • セキュリティグループ: Verified Access 用SG
  • エンドポイントドメインプレフィクス: 適当に記載(endpointなど)

sc_2024-09-05_15-47-42_5135

アプリケーションの詳細には 接続先ドメインおよび、 そのACM証明書を選択します。

sc_2024-09-05_15-47-54_30413

作成後、ステータスが Active になれば OKです。 エンドポイントドメインの値をメモしておきましょう。

sc_2024-09-05_16-23-19_12000

Route 53 CNAMEレコード

CNAMEレコードに アプリケーションドメイン → エンドポイントドメイン の内容を登録します。

sc_2024-09-05_15-55-47_21232

接続確認

実際にアプリケーションドメインにアクセスしてみます。 すると IAM Identity Center ポータルに遷移して、サインインが求められます。

sc_2024-09-05_17-58-26_2087

認証情報を入れてサインインすると、リダイレクトされて 静的サイトを表示できました。

sc_2024-09-05_16-30-26_3361

おわりに

以上、IAM Identity Center ユーザー向けにS3静的サイトを提供してみました。

余談ですが静的サイトジェネレーターである MkDocs を入れて表示させてみました。

sc_2024-09-05_16-43-40_682

問題なく表示されます。 (スラッシュ / 終わりを index.html にリダイレクトするリスナールールを入れると、 ページ遷移もできました)

ガイドラインを静的サイトで構成して、 AWS利用者に向けて公開する、といった用途にも使えそうです。

以上、参考になれば幸いです。

参考

https://aws.amazon.com/jp/verified-access/

https://dev.classmethod.jp/articles/aws-verified-access-components/

https://dev.classmethod.jp/articles/verified-access-generally-available/

https://dev.classmethod.jp/articles/s3-content-delivery-from-alb/

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.